Conventionally, in a multi-character networked game, a character may be controlled by multiple methods, which can change based on a current state of the game. For example, a user-controlled character may be controlled by a user's input from a controller or keyboard on the local machine, but may be controlled by some network interface on a remote machine. To illustrate, a rideable character, when it is not being ridden, may be controlled by an artificial intelligence behavior tree or state machine on a local machine and by some network interface on a remote machine. Once the user-controlled character mounts the rideable character, it may be controlled by the user's controller input on the local machine and still by a network interface on a remote machine. This may be further complicated if a user-controlled character on the remote machine mounts the rideable character that was on a network interface because the rideable character may need to change from network controlled to user controlled on the remote machine and from AI controlled to network controlled on the master machine.
Existing solutions may require hard coding on a case-by-case basis. Non-user-controlled characters may be developed separate from user-controlled characters such that little to no functionality is shared. User-controlled characters may not easily transition to being controlled by other sources. If such functionality is required, explicit coding for a specific character may be necessary. Networking may be implemented in a very literal manner with large amounts of network traffic being dedicated to updating where a character is located and what animations are being played on the character. The network implementation of characters may require extrapolating to make educated guesses about where the master character is at a given moment and what animation is playing at what frame. As such, existing approaches may be very inflexible and unforgiving making for very choppy looking characters on the network.